• 本文
• ノート
• 編集
• 差分

SMRなHDDベンチマーク

2022-08

SMR（瓦記録）HDDとは何か？†

• こんなやつ(PC Watchの記事)ですね。（手抜き説明）

https://akiba-pc.watch.impress.co.jp/docs/mreview/rental/737407.html

• 要は、書き込みヘッド（トラック幅）はこれ以上細くできないけれど、
• 読み出しヘッドは書き込みヘッドより細いものも読めるので、
• 瓦みたいにトラックをずらし書きすればいいんじゃね？説。

今回の計測対象†

• ST6000DM003 (6TB) です。

前提条件†

• SMRは、重ね書きをするときは、一度に全部書き（一筆書き）をせざるをえない。
• 重ね書きで、仮に半トラックずらしで書き込めるとしたらトラック密度は倍近くになる。2/3トラックずらしで書き込めるとしたらトラック密度は1.5倍になる。
• 2018年現在の技術でプラッタ当たりの容量は1.33TB程度なのに、2TB/プラッタの記録容量のSMR製品が出てきているということは、2/3トラックずらしぐらいで追記しているのではないか？【要検証】

• 読むときは瓦のペナルティは特にはない。

• それで、問題は、瓦の重ね回数というか１本書くのに何回転粘るか、という数値だが、今回はこれを推測したい、という野望。
  • ちなみに5400rpmなので、秒速90回転。
  • 転送速度が185MB/sなので、１回転あたり約2MB。
  • 瓦を何枚重ねるかだが、さすがに2,3枚だと容量は殆ど増えない。たぶん8枚以上だと思われる。
  • しかし、90枚ぐらい重ねると一筆書くのに丁度１秒掛かる。
  • 仮に10枚瓦だとすると、一筆書くのに1/10秒掛かるわけだ。

測定プログラム†

• 普通にC言語で書いた。- ダウンロード

測定方法†

• 書き込みのシーク位置は6TBのうちの2.5TB～3.5TBの間の1TBをランダムに選択するようにした。
• 書き込み開始オフセットは、書き込みブロック長の整数倍の場所から行うようにした。
• 適度に処理負荷を掛けるために、３スレッド同時に動かして、各書き込み速度の和を取っている。

測定結果†

ST6000DM003†

• 書き込みブロック長が8MB,4MB,2MBのときは書き込み速度に相当なムラがあるようだった。
  • おそらくこれらのブロック長のときはバックグラウンドで瓦の書き戻しタスクが走っている。
  • 16MB以上の時にもバックグラウンドで瓦の書き戻しタスクが走っている可能性はあるけれど、ほとんど目立たない。

• 書き込みブロック長が2MBのときに書き込み速度が早くなっている。
  • これは、最初の１０秒ぐらいはメディアキャッシュへの書き込みのみになっていて、シークが少なくて非常に高速だった可能性がある。

• 4MB,2MBの総書き込みサイズが少ないのは、時間節約のため（へたれ）

結論†

あくまでも推測するしかないが、

• 瓦１本分のブロックサイズはわかりやすい2のべき数ではなさそう。
• HDDの構造からして、１回転あたりの容量は場所ごとに異なるので、重ね回数を固定にすると外周ほど大きくなるし、重ね回数を外周と内周で調整したとしても、ぴったり16MBのような値にするのは難しい。

• 少なくとも2,4,8MBよりは大きい。
• 16MB～32MBあたりのどこかではないだろうか（つまり8トラック～16トラック分）【要検証】

• また、ブロック長が256MBということはありえない。
  • DRAMバッファが全然足りないし、一筆書きに1秒以上掛かるので。
• 仮に16MBだとすると、瓦バッファをDRAM上に10本以上置ける。

感想†

• メディアキャッシュが邪魔をして、ブロック長をうまく測れない。
  • 測定戦略を練り直す必要がある。

• 瓦は思ったより性能良い。書き込みスレッドが３つぐらいでは全然へこたれないので、普通に使って問題ない。

• 注意点は
  • 書き戻しタスクが裏で走るので、スループットは変動する。
  • ファイルシステムのフラグメンテーションが酷い状態で書き込み負荷を多くかけると、microSD以下の速度になる。
  • 理想を言えば、クラスタサイズを大きくしてフォーマットし、動画とかバイナリーイメージのような大きなファイルを、なるべくドカンと書いて、読み出し主体で使用するのが良い。

• これ、ホストマネージドに切り替える何か、とか、このブロック長で書けば書き戻しタスクは不要になる、みたいな裏技は欲しい気がした。

メディアキャッシュが邪魔をして、ブロック長をうまく測れない。†

• マジコレ。
  • こいつがなければ、タダのクソ低性能ディスクになる。
• 戦略１）総書き込み容量をメディアキャッシュよりはるかに大きな値にして計測。
  • メディアキャッシュは一説によると30GB程度らしいので、最低でも100GBは書く。
  • 書き戻し処理の終了時間を検出できればメディアキャッシュの挙動も含めて計測できるのだが・・・（シーク音センサーでも付ける？）
• 戦略２）メディアキャッシュの書き戻しが大量発生するように、小さなランダム書き込み要求を大量に与えたのち、小さなランダムリードを行なって、レスポンスタイムから、１回の一筆書き時間（無応答時間）を推測する。
  • この方法はそれぞれのシーク時間が加わるので推測は誤差が大きい。
  • 書き戻しに必要な読み込み処理と小さなランダムリードのどちらが優先されるのかは不明。

メディアキャッシュとは何か？†

• （書き込みの）ジャーナルログのようなもの。恐らく、メタデータ＋書き込みデータ
  • いちいち瓦に直接書いていたら、タダのクソ低性能ディスクになるので、瓦ではない領域を作ってそこに瓦に書いたつもりのデータをログとして書いておく。
  • そのログがある程度溜まってから、瓦の書き戻しを纏めて行う。
  • お纏めすることによって、複数回必要だった書き戻しを１回で済ませる
  • バックグラウンドタスクのように書き戻し処理というかジャーナルログの消化を行っている模様。
• もしかしたら、ジャーナルではなくて、ただのディスクキャッシュonディスク、なのかもしれないけれど、そうするとこんどは、瓦から読む動作が入るので（その分遅くなるから）、ジャーナル説に一票。

• ・・・と、言うことは、瓦から読み込むときは、元の瓦記録に加えて、ジャーナルログに書かれている「最新の」データを（複数あれば全部、新しいものを優先する形で）上書きしたものをホストPCに返却する必要がある。
  • もっと言うと、30GBぐらいあると言われるジャーナルログの、メタデータ部分だけはオンメモリーで保持してないと検索できないじゃん・・・

• 瓦の読み込みは、処理時間ペナルティ・ゼロではない（笑）

その他